<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>



<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.08">
<LINK rel="stylesheet" type="text/css" href="tutorial.css">
<TITLE>
Issues in Problem Modelling
</TITLE>
</HEAD>
<BODY >
<A HREF="tutorial080.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="tutorial079.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="tutorial082.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>

<H2 CLASS="section"><A NAME="htoc152">11.2</A>&nbsp;&nbsp;Issues in Problem Modelling</H2>

A good formalism for problem modelling should fulfil the following criteria:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Expressive power</B> - 
 Can we write a formal model of the real world problem?
<LI CLASS="li-itemize"><B>Clarity for humans</B> - 
 How easily can the model be written, read, understood or modified?
<LI CLASS="li-itemize"><B>Solvability for computers</B> - 
 Are there good known methods to solve it?
</UL>
Higher-level models are typically
closer to the user and close to the problem and therefore
easier to understand and to trust,
easier to debug and to verify,
and easier to modify when customers change their mind.
On the other hand, it is not necessarily easy to see how they can be
solved, because high-level models contain
high-level notions (e.g. sets, tasks) and
heterogeneous constraints.<BR>
<BR>
The constraint programming approach also addresses one of the classical
sources of error in application development with
traditional programming languages: the transition from a
<EM>formal description</EM>
of the problem to the <EM>final program</EM> that solves it.
The question is: Can the final program be trusted?
The Constraint (Logic) Programming solution is to
<UL CLASS="itemize"><LI CLASS="li-itemize">
Keep the initial formal model as part of the final program
<LI CLASS="li-itemize">Enhance rather than rewrite
</UL>
The process of enhancing the initial formal model involves for example
<UL CLASS="itemize"><LI CLASS="li-itemize">
Adding control annotations, e.g.
 algorithmic information or heuristic information.
<LI CLASS="li-itemize">Transformation:
 Mapping high-level (problem) constraints into
 low-level (solver) constraints,
 possibly exploiting multiple, redundant mappings.
</UL>
There are many other approaches to problem modelling software.
The following is a brief comparison:
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B>Formal specification languages (e.g. Z, VDM)</B><DD CLASS="dd-description">
 <A NAME="@default293"></A>
 More expressive power than ECLiPSe, but not executable
<DT CLASS="dt-description"><B>Mathematical modelling languages (e.g. OPL, AMPL)</B><DD CLASS="dd-description">
 <A NAME="@default294"></A>
 Similar to ECLiPSe, but usually limited expressive power,
 e.g. fixed set of constraints.
<DT CLASS="dt-description"><B>Mainstream programming languages (e.g. C++ plus solver library)</B><DD CLASS="dd-description">
 <A NAME="@default295"></A>
 Variables and constraints are "aliens" in the language.
 Specification is mixed with procedural control.
<DT CLASS="dt-description"><B>Other CLP/high-level languages (e.g. CHIP)</B><DD CLASS="dd-description">
 <A NAME="@default296"></A>
 Most similar to ECLiPSe. Less support for hybrid problem solving.
 Harder to define new constraints.
</DL>
<HR>
<A HREF="tutorial080.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="tutorial079.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="tutorial082.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
